自動勉強会 vol.5 GUIアクセシビリティ対応

11/19(金) 20:00 - 22:00

すべてのfocusableな要素にtab sequence がある必要はない（モードがある。たとえばラジオボタンはタブ上では一個）

グラフィックツールでは、マウスユーザーにもkbdのメリットある（この例だと真横に直線とか引けるよね）

前にブラウザ拡張機能で Vimium ってのがあって、リンク押すモードになると適当なキー打って画面に見えてるリンクを一発で選択できるように

ワイアリア、ウェイアリアなど読み方あり

HTMLのパーツ<input> <form> など、それだけでは今のWebAppでは従来のHTMLでは足りないので追加の意味付けをする

通常のフォーム部品のタグを使っていれば関係ない？

普通の使い方をしているならマシンリーダブルとして問題がないが、モーダルなどはwai-aria使うと支援技術に伝えられる

divなどでムリヤリ作っているやつ

ボタンの表現なども role-button としてやれば伝わるけど、 <button> タグが使えるならそっち使って『HTMLで表現できるものはHTMLで表現しましょう』が通説

wai-aria が作用するのは「アクセシビリティオブジェクトモデル（AOM）」（支援技術用のツリー、DOMとは別のツリー）これを介して伝える

devtools の Elements の Accesibilities

AOMを使っているのはスクリーンリーダーとか一部。テストとかスクレイピングなど、タグ名とかに依存しているものも多い

開閉している、とか選択している、といった「状態」の保持はHTMLは弱い

wai-ariaとHTMLは相互進化

パラグラフ、ダイアログなど。ブラウザが持っている情報を他に伝える

jsでAOMを取得するAPIがasyncなので、たぶん支援技術やdevtoolsやjsが必要とする、アクセスするときだけ作ってる？

提案中のAPI。テストツール等からも使えるようになるので嬉しい

Element.ariaLabel = ... なんかもAOMがやろうとしている

DOMとやりたいこと共通してきてるので、jsのDOMチームにAOMチームが提案して組み込んでもらう運用に

これでスクレイピングとかうまく行かないならアクセシビリティの実装も足りてないんじゃないか？　みたいに言えるわけですね

例

wai-aria authoring practices を見ると例が載っている

アクセシビリティ的には、一時停止ボタンなどあるとよい（読み上げの観点を加えると考慮する点が増える）

「見える」人向けのUI

そもそもカルーセル、文字無いイメージ画像を見せるだけのやつもありますもんね

2ページ目以降の閲覧率が10%にも満たないので、要らないよねって話でますね

3枚しかないって言われてDOM複製しなきゃいけなかったり

要素のドラッグ&ドロップ

用途によって難易度が異なる

順番の入れ替え

→ 選択＋いっこ移動 で代替可能

二次元平面上の自由移動

レベルAA（例外）

軌跡が重要な場合

今日の例であったように、マス目であれば→←↓↑で移動可能

スクリーンリーダー上で「上下左右に移動可能」って何さ？

スライダーはあるけど、二次元に移動可能なものを表現するものはHTMLにもwai-ariaにもない

カラーピッカーは2D移動使うので、Adobeさんとか噛んでるんじゃないか

「ただし、その根本的な機能が利用者の動作による始点から終点まで続く一連の軌跡に依存して実現されている場合は除く。」というフレーズは、キーボードから合理的に操作できないものを区別するために含まれている。

ファイルのドラッグアンドドロップは、ファイル選択の機能 <input type="file"> があればOKだったりしますね

バウンティングボックスはphotoshopみたいにバウンティングボックスプロパティがあればいいような気がしました

x, y, w, h の数値入力input

バウンディングボックスの複数選択も難しそう

ツリーの編集はDnDあるとやりやすいよね

Finder.app とかVSCodeのアクセシブルな実装とかどうなってるか知りたいですね

VSCodeのやつ、なくてはならない感じの感想が出てる→けっこうVSCodeは力入れてるっぽい

自前モーダル

ただしモダンブラウザで安心して使えるまでは自前モーダルでやっていてね、とのこと

おすすめ

backdropは<dialog>の機能で、::backdrop疑似要素があるよ

下がスクロールできちゃうの気になるな……

これが有効になるの、ダイアログの中にフォーカスがあるときだけなので結局手動でやらないといけないんですけどね

ダイアログの自前実装、めっちゃ副作用的な実装しますね

ReactなのにめっちゃDOM書いてるじゃん

<portal>とか必要になるし

バウンディングボックスのアクセシビリティとかどうなるんだろう

ノードベースGUI

AOMだけ見られるブラウザ欲しくなりますね

それってスクリーンリーダーにビジュアルフォールバックが付いたものでは？

windows だと エービューワー というのがある

普段はスクリーンリーダーでチェックするんですか？

ユーザビリティのチェックでは使いますけど、普段の開発はdevtoolsのAccesibilityで見ますね

MacのOSのボイスオーバーはあまり……iOSのは使いやすい

WinのOSSの NVDA はやりやすいという話。フォーカスモードとブラウズモードの切り替え。Macのほうのは奥へ奥へ入っていってしまうのと、日本語・漢字の読み上げが弱いっぽい

スクリーンリーダー、読み上げ音声の音質・声質なんかが重要視される、知らない観点

strong タグを強調して読み上げさせるか、しないかみたいな設定もあるみたいです

UIのこだわり

フォントが違うみたいな話

スクリーンリーダーユーザーは速度を上げて読み上げることが多いので、そのときの聞き取りやすさ的に女声のほうが向いている

→ そういう意図はないのにジェンダー的な問題に発展したりした

kyoko（拡張）聞き取りやすいです

OSの機能でマウスをキーボードで操作するやつって使われてるんでしょうか

使われてる

ALSの患者さんなどはTabとEnterの2つの操作などができないので、押すエリアを分探索的にしてタイミングで押したりクレーンゲーム的にやったり

1入力しかなくても意外といけますね

そもそもそのアプリの内容的にアクセシビリティいるのか問題（お絵かきアプリを目が見えない人が使うのか）

誰のためのアクセシビリティを削るか。かな

全く使えない人への対応ではなく、使える人の裾野を広げるアクセシビリティ

全盲の人でも自分の目の前にあるものを見える人に共有する意図でカメラを使ったりするので、ペルソナの思い込みで狭めずに「自分の実装できる範囲で対応します」していくのがいいよ

たとえば目的地までの地図がWebサイト上にあったりするとき、alt="地図" ってするだけでなく、印刷して紙を見える人に見せて聞いたりする

何も見えてなくても、見える人とコラボレーションしたり使い方をしたりするので狭めずにしておく

アクセシビリティでAIって使うんでしょぅか

Google Chrome とかだと画像の説明テキストを生成してたり、FBとかはaltを自動生成してる

コンテンツ提供者の意図はAIは見れないので、「何を伝えたいか」はauthor側が入れて界面を押し上げていかないと

Twitterの画像投稿とか ALT 入れる欄ありますよねー

めっちゃサボってる

昔、回線が細すぎて画像表示せずにネットサーフィンするとかありましたね

TwitterのCDNが死んでたとき、絵文字にも代替ラベル付いててちゃんとアクセシビリティやってるんだなって

絵文字は読み上げ側で自動でそれぞれの言語に変わるので翻訳いりませんね

でも文化が違うと困る

Tofu on fireみたいな話もあるし📛

「これは絵文字の説明ではあるのですが、ミームの意味を損なっています。その意図には旗の色が関係していますから」

晴眼者でもミームがわからなければ赤い旗が並んでいるだけなんで……

インターネット・ミームになっている画像やGIFもハイコンテクスト

絵文字3つ以上重ねない、とかありますがTwitterでめちゃ絵文字連続で使いがち…

「雰囲気」を表すための音を付けられないか？　みたいな話

Success_Kid.wav

Awesome_Awkward_Penguin.wav

Appleの発表とかでも「dynamic music」ってただの「音」ではない提示

マイクラのSEも画面に文字で出せますよね

あれいいですよね

Java版

ちょっとズレますが○✕は英語圏では伝わらないとかありますね

僕ら的には識字可能という前提があるけど、識字障害があったりする場合には絵文字・図版・アイコンがあったりするほうが

お絵かき・デザインアプリ

例えばadobeとかfigmaとかどこまでやってるんだろう

音楽アプリ

全盲の方でも作曲する人多いんで、ネイティブの音楽アプリはスクリーンリーダー、キーボードで操作できるやつは多い

YouTubeとかどうなってるんだろう

あ、ボタンとかに aria 付いてました。

聴覚障害の方向けにハプティックに変換したり見た目にしたりしてベースのリズムだけでも伝えようというのがある

感覚を変換

VJとかも

あーありますね。古いWindowsMediaPlayerで順繰りに見て遊んでました

視線入力

アイトラッカー、ドライアイ持ちには厳しいツールでした。。

光過敏症の人とか

逆にコントラスト比を落とす

コントラストの『変更を検知する』

Canvasのアクセシビリティ

divを浮かせてる

グランブルーファンタジーで見たことあるやつだ

docs を canvas に移行するって話で、ちゃんとアクセシビリティ担保するよって言ってた

選択したセルによらず、ずっと一つのdivにフォーカス当て続けてDOMの描画としては最小限にしつつ中身をがしがし書き換える

無限スクロールの<canvas>＋場所が決まってる<div>

V-AOMを作る提案→全然うまく行ってない

そこでしか使われない→障害を持っていること自体がコンテンツ作者に対して露出するフィンガープリンティング問題

https://gyazo.com/550fde2462379975d5ba9d0f428a835c

WebViewがしんどいみたいな話

ウェブビューはiOSとAndroidで挙動がかなり違うように思います。

株価の読み上げ

Since we’re all looking at Stocks today…

グラフの形をテルミンみたいな音で出してくれる

iOS App もAOMを持ってて、Xcodeで見れる

アクセシビリティ版Playbookをビジュアルリグレッションテストやって、アクセシビリティモデルのスナップショットテストやってる

アクセシビリティに対応したライブラリとか

すげー、複数選択もキーボード操作できる

headless-ui

web標準的なものをきちんと揃えてる

tailwindと使ってなんぼかな

alpine.js 対応という話も出ていたんですが

alpine、名前的に軽く小さく方面ですよね（Docker使いの感想）

拡張性

デザイントークンの土台として使える

きちんと設定すればwrapコンポーネントいらない

用意されてるもの以外は自分で作らないといけないけど、テーマでプロパティを全部いじれるので

React Ariaは支援技術と振る舞いを定義していて、この上でデザインシステムやUI ライブラリを構築できる

いわば「アクセシビリティ対応ライブラリ」をつくるためのライブラリ

挙動を抽出してUIと分離して使えるということの便利さ

（自己解釈も入ってますが、）スクリーンリーダーはCSSのdisplay:hiddenとかからも影響受けちゃうので。

jsは状態(hoverとか)も持ちやすい。振る舞いを担保しているところで、デザイントークンを導入したいひとたちが「これを使えばいいじゃん」という

振る舞いを管理することで、振る舞いをwai-ariaに変換するところまでやってくれる

スタイルは自分で当てられる

IE11が対応してない……

IE切ったら汎用的なhooksはReactAriaに置き換えていく予定

isFocusVisible ? "shadow-outline" : ""

focusPropsとかがwai-ariaにも伝えられる

wai-ariaの属性を知らなくても、これを使えば状態の定義からいい感じに属性が入る

フォーカス管理（ある程度複雑なこと）とかは自分でやらなきゃいけないので、ユーティリティって感じはある

BootstrapとかのCSSフレームワークと同じで、ライブラリに無いやつは自分で作らないといけない（デザインも振る舞いも同じこと）

Vuejsだと何がいいのだろうか

もしかして複雑GUI作ってる人はReactが多い？

web系全体的にReactちょっと強めかも？

ちなみにVuetifyのアクセシビリティはちょっといまいちですね

東京都コロナウイルスサイト、試験したらどうしようもない場所がいくつかあって書き換えないといけないものがある。全体的にはある程度できてるんだけど

Rikiya Ihara / magi (@magi1125)

東京都新型コロナウイルス感染症対策サイトのウェブアクセシビリティ試験結果が公開されました。JIS X 8341-3:2016の適合レベルAAに準拠したと判断しています。ここをひとつのマイルストーンとして、よりアクセスしやすく利用しやすい形を引き続き模索していきます。

canvasの読み上げはできなくても、下の方に「テーブルを表示」ボタンがあってそちらで提供できてたりする

ほか疑問など

disabledな理由の提示をどこでするか？

でもモーダル出てきたらうざくない？

disabledにして操作不能にする / 理由を提示する は競合する

エラーメッセージはそれ用の aria- 付けて提示しないとスクリーンリーダーが見落とす

4.1.1

wai-aria の live region

twitterの文字数制限は role-progressbar で割合に転写して、スクリーンリーダーの機種によっては高めの音を出す

NVDAは出してくれる

プログレスバーということは、ファイルダウンロードとかでも出してくれる？

仮装大賞的な……（世代的に通じないかも）

カウントダウンをスクリーンリーダーでどうやって適切に伝えようかな

あとdd日hh時間ss秒、とか、秒ごとの更新がタイムラグあるし、一秒ごとに変わるものを全部読み上げさせるのも違うし……

"あとdd日hh時間ss秒で、刻々と変化しています" までラベルにしてしまってもよい

"あとdd日hh時間ss秒" まで読み上げさせて、あとは単なるチクタク音のBGMだけでもいいよね

ariaのカウントダウンも提案ある

達成基準 2.2.3: タイミング非依存を理解する

AAA 制限時間を設けなくても使える手段がないか検討しましょう。くらいで・・

https://www.youtube.com/watch?v=TXdk2BetNoU

うちの同僚が使ってるやつは上にボタンがついてて矢印キーとして使えたりしたと思います

点字ディスプレイの読み上げに対する優位性は？

何回も同じところ読める

読み上げずっと聞き続けるので聴力に悪い影響出ることもしばしば

盲聾だと読み上げ使えないし……

聞きながら読める

（補助金の想定問答にいくつか書きました）

アレクサ・音声変換という手段も……

uuidを付与するみたいなのが１つの手段かもです

useIdはIDを文字列で扱えるから、aria-labelledbyなど複数のIDを受け入れるユースケースに適合するそう

二次元平面を移動するハンドルの role, name, value で困った話

点字ディスプレイの使用感知りたいけど、とんでもなく高いんですよね・・

情報取得手段の選択肢が沢山あるのもいいですね

noyan — 今日 23:10

Combobox Keyboard Interaction for the Input

Note: With the exception of the dialog popup variant, DOM Focus should be maintained in the combobox input, and the assistive technology focus within the popup should be controlled using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.

masuP9 — 今日 23:10

このIDはレンダリング順に依存なので、React18で死にそうな印象があります

あのツールのアクセシビリティってどうなってるのコーナー

Photoshop

Illustrator

Figma

VSCode

Terminal

Vim

Scratch

Twitter

Slack

PowerPoint

ふと思い出したやつですが貼ってみます（電気刺激で踊るやつ）。

参考URLとか情報

mspaint.exe を外部ツール使って視線で操作してる例